Uniform resource discovery and activation

ABSTRACT

A function instance associated with a resource specifies one or more interfaces for accessing the resource. The function instance further includes functionality to return an entity operable to implement the specified interface.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application60/546,671, filed Feb. 20, 2000, which is hereby incorporated herein bythis reference.

This application is related to U.S. patent application titled “UniformResource Discovery” [Matter No. 384057.01], filed Feb. 18, 2005; U.S.patent application titled “Uniform Resource Discovery and API Layering”[Matter No. 384059.01], filed Feb. 18, 2005; and U.S. patent applicationtitled “Uniform Resource Discovery Provider” [Matter No. 384060.01],filed Feb. 18, 2005, each of which is hereby incorporated herein by thisreference.

TECHNICAL FIELD

The technology described herein relates generally to the uniformdiscovery and use of various types of computer resources.

DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example of one possible computing device in whichthe various technologies described herein may be implemented.

FIG. 2 illustrates one implementation of a system in which uniformresource discovery, as described herein, may be carried out.

FIG. 3 illustrates a generalized representation of one implementation ofa function instance.

FIG. 4 illustrates a generalized representation of one implementation ofan API layer.

FIG. 5 illustrates a generalized representation of a tree structure thatmay be used by a mapped function instance provider.

FIG. 6 illustrates a generalized operational flow including variousoperations that may be performed in retrieving function instances.

FIG. 7 illustrates a generalized operational flow including variousoperations that may be performed to service a request for functioninstances.

FIG. 8 illustrates a generalized operational flow including variousoperations that may be performed by a mapped function instance providerto service a request for function instances.

FIG. 9 illustrates a generalized operational flow including variousoperations that may be performed by a function instance in response toan activation request.

DETAILED DESCRIPTION

Described herein are various technologies and techniques directed to thediscovery and use of computer resources. More particularly, describedherein are, among other things, systems, methods, and data structuresthat facilitate the discovery of, and access to, computer resources inmanner that is uniform across disparate types of resources.

Included in the various technologies and techniques described herein isa unique discovery module that enables applications to retrieveinformation about various resources and access these resources in auniform manner. In these implementations, the application uses thediscovery module to request information about, or access to, one or moreresources. In response to the request, the application receives one ormore “function instances,” each of which is associated with a singleresource that satisfies the request.

Function instances may have various forms and formats. For example, insome implementations, a function instance is an object that includes orreferences metadata about its associated resources. In someimplementations, a function instance also includes or references someinformation or mechanism by which its associated resource may beactivated. As used herein, activation refers to creating or makingavailable a programmatic mechanism, such as an API or the like, by whichan application may access or use a resource.

Regardless of the particular form or format of function instances, inaccordance with the various implementations described herein, functioninstances will in general have uniform fields, which may containreferences to resource metadata and activation data, and a uniform API,enabling users of function instances to interact with function instancesin the same manner, regardless of the resources represented by thefunction instances.

In some implementations, function instances are created using functioninstance providers. In these implementations, each function instanceprovider is associated with a given set or type of resources. In theseimplementations, function instance providers also include appropriatemechanisms to enumerate and create function instances for the set ortype of resources associated therewith. For example, and withoutlimitation, one function instance provider may enumerate and createfunction instances for Universal Plug and Play resources, anotherfunction instance provider may enumerate and create function instancesfor Web Service Discovery resources, yet another function instanceprovider may enumerate and create function instances for Simple ServiceDiscovery Protocol resources, etc.

In some implementations, the determination as to which function instanceprovider is appropriate for which kinds of requested resources is madeby a provider management module. In general, the provider managementmodule keeps track of the available function instance providers. When arequest for function instances is received by the provider managementmodule, for example from the discovery module, the provider managementmodule then selects an appropriate function instance provider to satisfythe request, and sends a request for function instances to the selectedfunction instance provider. The function instance provider thenenumerates its associated resources or otherwise queries its resourcesfor information, creates one or more function instances to representresources that satisfy the request, and returns the function instancesto the provider management module.

In accordance with some implementations, a particular type of functioninstance provider, referred to herein as a mapped function instanceprovider, presents function instances from multiple other functionproviders in a uniform manner using configurable categories. Functioninstances provided by a mapped function instance provider may bereferred to more specifically as mapped function instances.

As noted above, in some implementations, each function instance includesor references metadata for its associated resource. In someimplementations, applications may access this metadata to obtain an APIwith which they can interact and control the resource associated withthe function instance.

In some implementations, each function instance enables an applicationto obtain an API for the resource in a manner independent of theresource and function instance. In one such implementation, anapplication may request that a function instance “activate” a specificAPI. If the function instance supports activating the requested API, aprogrammatic entity (e.g., a factory object, or the like) is thencreated, which uses data associated with the function instance to createthe requested API.

In some implementations, in the case where a particular mapped functioninstance represents another mapped function instance, a functioninstance provider may present function instances that support activatingmultiple APIs. In this implementation, a mapped function instance thatrepresents other mapped function instances may support activating APIsfor the function instance it represents, and also support activatingAPIs for the underlying function instances.

Example Computing Environment

FIG. 1 and the related discussion are intended to provide a brief,general description of an exemplary computing environment in which thevarious technologies described herein may be implemented. Although notrequired, the technologies are described herein, at least in part, inthe general context of computer-executable instructions, such as programmodules that are executed by a controller, processor, personal computer,or other computing device, such the computing device 100 illustrated inFIG. 1.

Generally, program modules include routines, programs, objects,components, data structures, etc., that perform particular tasks orimplement particular abstract data types. Tasks performed by the programmodules are described below with the aid of block diagrams andoperational flowcharts.

Those skilled in the art can implement the description, block diagrams,and flowcharts in the form of computer-executable instructions, whichmay be embodied in one or more forms of computer-readable media. As usedherein, computer-readable media 108 may be any media that can store orembody information that is encoded in a form that can be accessed andunderstood by a computer. Typical forms of computer-readable mediainclude, without limitation, both volatile and nonvolatile memory, datastorage devices, including removable and/or non-removable media, andcommunications media.

Communication media embodies computer-readable information in amodulated data signal, such as a carrier wave or other transportmechanism, and includes any information delivery media. The term“modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationsmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media.

Turning now to FIG. 1, in its most basic configuration, the computingdevice 100 includes at least one processing unit 102 and memory 104.Depending on the exact configuration and type of computing device, thememory 104 may be volatile (such as RAM), non-volatile (such as ROM,flash memory, etc.), or some combination of the two. This most basicconfiguration is illustrated in FIG. 1 by dashed line 106. Additionally,the computer system 100 may also have additional features/functionality.For example, the system 100 may also include additional storage(removable and/or non-removable) including, but not limited to, magneticor optical disks or tape. Such additional storage is illustrated in FIG.1 by the removable storage 108 and the non-removable storage 110.

The computer device 100 may also contain communications connection(s)112 that allow the device to communicate with other devices. Thecomputer device 100 may also have input device(s) 114 such as keyboard,mouse, pen, voice input device, touch input device, etc. Outputdevice(s) 116 such as a display, speakers, printer, etc. may also beincluded in the computer system 100.

Those skilled in the art will appreciate that the technologies describedherein may be practiced with other computing devices other than thecomputing device 100 illustrated in FIG. 1. For example, and withoutlimitation, the technologies described herein may likewise be practicedin hand-held devices, multiprocessor systems, microprocessor-based orprogrammable consumer electronics, network PCs, minicomputers, mainframecomputers, and the like.

The technologies described herein may also be implemented in distributedcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed computing environment, program modules may be located inboth local and remote memory storage devices.

While described herein as being implemented in software, it will beappreciated that the technologies described herein may alternatively beimplemented all or in part as hardware, firmware, or variouscombinations of software, hardware, and/or firmware.

Turning now to FIG. 2, illustrated therein is a system 200 in whichuniform resource discovery may be carried out. Included in the systemare an application 210, a function discovery module 212, and a number ofresources 218. Generally, the application 210 may be any program,process, or the like, that is operable to interact with or control thefunction discovery module 212 and/or one or more resources. In general,a resource may be any hardware, software, or combination of hardware andsoftware that provides functionality to the application.

In accordance with one implementation, the application 210 is a programthat displays a graphical representation of available resources.However, those skilled in the art will appreciate that the applicationcan be any process that is operable to communicate with or make use ofany resources, for any purpose.

Included in the function discovery module 212 is a discovery interfacemodule 226, a provider management module 228, a number of providers 214,and a mapped function instance provider 230. Also included in thefunction discovery module 212 are mapped function instance provider data232 and provider management data 234.

In general, the discovery interface module 226 is a programmatic entitythat provides functionality to receive requests from an application 210and also includes various routines operable to handle the requests. Insome implementations, the discovery interface module 226 is operable tocommunicate with the provider management module 228 to retrieve functioninstances in response to application requests.

For example, and without limitation, in accordance with oneimplementation, the discovery interface module 226 comprises an API thatincludes methods that enable an application 210 to request functioninstances for specified resources. In response to such a request, thediscovery interface module 226 communicates with the provider managementmodule 228 to retrieve function instances that represent the requestedresources.

In general, the provider management module 228 is a programmatic entitythat accepts requests for function instances from the discoveryinterface module 226. In some implementations, as described below, theprovider management module uses the provider management data 234 and theone or more providers 214 and 230 to retrieve function instances, whichthe provider management module then returns to the discovery interfacemodule 226.

For example, and without limitation, in accordance with oneimplementation, the provider management module 228 comprises executablecode that responds to requests from the discovery interface module 226by identifying a provider using information such as the providermanagement data 234 and the information included with the request. If aprovider that can service the request is found, the provider managementmodule 228 requests that the identified provider supply a set offunction instances according to the request from the discovery interfacemodule 226.

In general, in one implementation, the providers 214 are programmaticentities that receive requests for function instances from the providermanagement module 228. In response to a request from the providermanagement module, a provider enumerates or queries the resources withwhich it is associated, and creates and returns corresponding functioninstances to the provider management module. In some implementations,providers might also support activation of application programminginterfaces.

In accordance with various implementations described herein, eachprovider is associated with a predefined set or type of resource. Forexample, and without limitation, one function instance provider may beassociated with Universal Plug and Play resources, another functioninstance provider may be associated with Web Service Discoveryresources, yet another function instance provider may be associated withSimple Service Discovery Protocol resources, etc.

The particular manner in which a provider module 228 enumerates andcreates function instances may be dependent on the type of resourceswith which it is associated. For example, in the case where a providermodule 228 is associated with Plug and Play resources, upon receipt of arequest for a function instance or function instances, the providermodule may use a Plug and Play-specific API to enumerate its associatedPlug and Play resources. The provider module may then create and returnfunction instances that represent the Plug and Play resources.

In some implementations, the providers 214 and 230 can be supplied byparties other than the party or parties providing the function discoverymodule 212.

In general, the mapped function instance provider 230 is a particularimplementation of a provider 214 that supports the creation of mappedfunction instances. As used herein, a mapped function instance is afunction instance that is associated with at least one other functioninstance.

The mapped function instance provider 230 receives requests for functioninstances from the provider management module 228. In response, itcreates and returns mapped function instances and, in someimplementations, does so using data from the mapped function instanceprovider data 232. In some of these implementations, the mapped functioninstance provider data 232 defines mapped function instances andspecifies categorization and activation information for such mappedfunction instances.

For example, and without limitation, in accordance with oneimplementation, the mapped function instance provider 230 provides acategory that supplies a single set of function instances for resourcesthat output audio but are of different underlying types. For example,and without limitation, this category could include Plug and Play audiohardware and Universal Plug and Play media renderer devices. In someimplementations, this category information is associated with the mappedfunction instance provider data 232.

In general, the mapped function instance provider data 232 contains dataassociated with the mapped function instance provider 230. For example,and without limitation, in accordance with one implementation, themapped function instance provider data 232 may include a hierarchicalset of nodes in a configuration data store (e.g., the registry invarious versions of the Windows® operating system, from MicrosoftCorporation of Redmond, Wash.). In addition, the mapped functioninstance provider data 232 may include one or more Extensible MarkupLanguage (XML) fragments in particular nodes, where the nodes representmapped function instance categories and the XML fragments containinformation associated with mapped function instances.

In general, the provider management data 234 contains data associatedwith the provider management module 228. For example, and withoutlimitation, in accordance with one implementation, the providermanagement data 234 is a set of XML fragments that contain informationassociated with function instance requests and providers 214.

It will be appreciated by those skilled in the art that the discoveryinterface module 226, the provider management module 228, and thevarious providers 214 and 230 may be implemented using variousobject-oriented or non-object-oriented technology. The selection of oneor another type of object-oriented or non-object-oriented technology isa matter of choice, and is often determined by such things as theunderlying operating system, etc.

However, in accordance with some implementations, one or more of thediscovery interface module 226, the provider management module 228, andthe various providers 214 and 230 are implemented as objects thatconform to the Microsoft Component Object Model (“COM”) specification.The COM specification defines binary standards for objects and theirinterfaces, which facilitate the integration of software components intoapplications.

Turning now to FIG. 3, shown therein is a generalized representation ofa function instance 300. The following description of FIG. 3 is madewith reference to the system 200 of FIG. 2. However, it should beunderstood that the function instance described with respect to FIG. 3is not intended to be limited to being used by, or interacting with,elements of the system 200.

In general, a function instance 300 represents a resource 218, eitherdirectly (e.g., by referencing the resource directly) or indirectly(e.g., by referencing another function instance). Function instances maybe used throughout the system 200 to represent and transfer resource andother function discovery information. For example, the providermanagement module 228 may retrieve function instances 300 from providers214 and provide function instances to the discovery interface module226, which provides function instances to the application 210.

A function instance 300 may be implemented as an object in anobject-oriented environment and embodied in a computer-readable mediumor media. However, it should be understood that the functionalitydescribed herein with respect to a function instance object 300 can alsobe implemented in a non-object-oriented fashion, and can be implementedon many types of systems, both object-oriented and non-object-oriented.

As shown, the function instance 300 includes a unique identificationfield 310, a resource metadata field 312, and an activation data field314. Additionally, in some implementations, the function instanceimplements a function instance interface 330. The interface defines aset of methods that any function instance object may implement.

In the implementation of the function instance 300 shown in FIG. 3,these methods implemented include a method to retrieve data stored inthe unique identification field 320, a method to retrieve resourcemetadata 322, and a method to activate the function instance 324.

It should be understood that, in some implementations, the informationreturned by the methods 320-324 may be made available directly by means,such as and without limitation, public object properties. In suchimplementations, the corresponding method may not be necessary. Forexample, if the unique identification field 310 can be retrieved byaccessing the field directly, then the get unique identifier method 320would not be necessary. Additionally, the methods may be made availabledirectly and without the use of an interface.

The unique identification field 310 contains data that, in someimplementations, uniquely identifies the function instance in a systemon which the function discovery module 212 is executing. Furthermore,the unique identification field remains constant even when the functiondiscovery module 212 or system 200 is stopped and restarted. Therefore,once an application 210 retrieves the unique identification value for aparticular function instance 300, the value can be stored and later usedto locate that function instance, and thereby, a particular resource.

The resource metadata field 312 contains data specific to the particularresource 218 represented by the function instance. In oneimplementation, the metadata may comprise a key/value table 340. In thistable, the keys 342 contain identifiers that identify the information ina particular key/value pair. For example, and without limitation, keyscould be “Friendly Name” 346 or “Manufacturer” 348. The value 344associated with a particular key contains the information described bythe key. For example, and without limitation, the value associated withthe “Friendly Name” key 346 could be “Primary sound card,” while thevalue associated with the “Manufacturer” key 348 could be “Company Name,Inc.”

Regardless of the way in which the resource refers to a particular pieceof metadata, in some implementations, the resource metadata field 312identifies the metadata in a consistent manner through the use ofstandard keys 342. For example, a particular resource 218 may make itsfriendly name accessible using a resource-specific property called“Name,” while another resource 218 may make its friendly name accessibleusing a method called “GetMyCommonName.” In both cases, the resultingmetadata could be represented in the function instance resource metadatausing the same key, for example and without limitation, using “FriendlyName” 346.

It should be noted that the metadata represented by the key/value table340 is not limited in any way to particular data. Furthermore, thekey/value table 340 can be implemented using many data structures.Finally, the key/value table 340 does not necessarily comprise theentirety of the resource metadata accessible using the functioninstance.

When called, the get resource metadata method 322 returns the datarepresented by the resource metadata field 312. As discussed previously,this method may not be necessary or required if the resource metadata312 is available through other means, such as through the use of apublic property.

The activation data field 314 includes or references information used bythe function instance 300 when an application 210 requests activation ofthe function instance. In one implementation, the activation data 314includes or references a table 350 of application programminginterfaces, or interfaces 352, that can be requested by an application210, and corresponding factories 354 that can create entities thatimplement the requested interface 352. When an application 210 requestsactivation from a function instance, it submits with the request aninterface that the entity returned by the function instance may support.

In one implementation, the activation data 350 included in or referencedby the field 314 may be examined for an entry that contains therequested interface 356. If the interface 356 exists, the correspondingfactory 358 is used to create an entity that supports the requestedinterface. This entity is then returned to the application 210 thatrequested the activation. For example, an application may request anactivation and specify the Foo interface 356. If the Foo interface 356exists in the activation data 350, the corresponding Foo factory 358 isused to create an entity that implements the Foo interface.

It should be understood that while the terms “interface” and “factory”are often associated with object-oriented environments, thefunctionality enabled by the activation data field 314 is not limited toany particular environment or system and can also be implemented innon-object-oriented systems. Furthermore, the activation data table 350can be implemented using many data structures. Finally, the activationdata table 350 does not necessarily comprise the entirety of theactivation data used or maintained by the function instance 300.

The activate method 324 uses the activation data 350 to create a factorythat in turn may create an entity that supports the requestedapplication programming interface. As discussed previously, this methodmay not be necessary or required if the activation data included in orreferenced by the activation data field 314 is available through othermeans, such as through the use of a public property.

Turning now to FIG. 4, shown therein is a generalized representation ofan API layer 400. In some implementations, an API layer may be a datastructure embodied in a computer-readable media or medium. The followingdescription of FIG. 4 is made with reference to the system 200 of FIG.2, the function instance object 300 and the activation data table 350 ofFIG. 2, and the tree structure 500 of FIG. 5. However, it should beunderstood that the API layer 400 described with respect to FIG. 4 isnot intended to be limited to being used by or interacting with elementsof the system 200, the function instance object 300 and the activationdata table 350, or the tree structure 500.

In accordance with some implementations, the mapped function instanceprovider 230 uses some number of API layers 400 and a tree structure,such as the tree structure 500, to enable enhanced categorization andactivation of function instances. An API layer 400 represents theinformation that may be used by the mapped function instance provider230 to retrieve function instances in a particular category and also toenable activation of the retrieved function instances. In oneimplementation, the API layers 400 and tree structure 500 are stored inthe mapped function instance provider data 232.

The API layer 400 illustrated in FIG. 4 includes a category ofunderlying function instance(s) field 412, a subcategory of underlyingfunction instance(s) field 414, a filter criteria field 416, a supportedinterface field 418, and a factory field 420.

The category and subcategory of underlying function instance(s) fields412 and 414 represent the category from which the function instancesreturned by this API layer 400 originate. The mapped function instanceprovider might not create any function instances that directly referencea resource 218. Instead, the mapped function instance provider 230 maycreate function instances that map to other function instances,including function instances created by a provider 214, or functioninstances created by the mapped function instance provider 230.

The category and subcategory of underlying function instance(s) fields412 and 414 specify the base set of function instances returned usingthe API layer 400, before any filtering performed using the filtercriteria field 416. For example, and without limitation, an API layer400 called “Audio Endpoints Local” might contain the necessary categoryand subcategory to specify a set of function instances that directly mapto sound hardware on the local computer system.

The filter criteria field 416 may contain or reference data by which theset of function instances returned using the API layer 400 is filtered.For a function instance to be specified by an API layer 400, it may beidentified by the category and subcategory 412 and 414, and may alsomeet the filter criteria specified in this field, if any filter criteriainformation is provided.

Filter criteria can include, for example and without limitation,particular values of resource metadata properties as well as supportedapplication programming interfaces. For example, filter criteria foraudio hardware might indicate that a resource metadata property named“Device Type” has the value “Audio Hardware” and that the functioninstance supports the “Audio” application programming interface.

The supported interface field 418 may contain the applicationprogramming interface supported by the function instances returned usingthis API layer 400. Alternatively, the supported interface field 418 maycontain no supported application programming interface, in which casethe API layer does not in and of itself support activation. In someimplementations, the data in or referenced by the supported interfacefield 418 populates a portion of the interface column 352 of theactivation data table 350 referenced by a function instance object 300.

In these cases, because the data exists in or is referenced by theinterface column 352, during activation, in some implementations thedata originating in the supported interface field 418 is used as part ofthe process that determines if the function instance supports arequested interface.

The factory field 420 may identify a factory entity that createsentities that support the interface specified in the supported interfacefield 418. Alternatively, if no such factory exists, the factory field420 may not identify a factory. As with the data in or referenced by thesupported interface field 418, in some implementations, the data in orreferenced by the factory field 420 populates a portion of theactivation data table 350 referenced by a function instance object 300.

In some implementations, the data in or referenced by the factory field420 populates a portion of the factory column 354 of the activation datatable 350. Because the data exists in or is referenced by the factorycolumn 354, during activation, the data originating in the factory field420 is used as part of the process that determines the factory entitythat can create an entity that supports the requested interface.

Turning now to FIG. 5, shown therein is a generalized representation ofa tree structure 500 which specifies categories and subcategories usedby the mapped function instance provider 230. The following descriptionof FIG. 5 is made with reference to the system 200 of FIG. 2, thefunction instance object 300 and the activation data table 350 of FIG.3, and the API layer 400 of FIG. 4. However, it should be understoodthat the tree structure described with respect to FIG. 5 is not intendedto be limited to being used by or interacting with the system 200, thefunction instance object 300 and the activation data table 350, or theAPI layer 400.

The tree structure 500 represents a conceptual model of the category andsubcategory relationships that can be used by the mapped functioninstance provider 230. The tree structure 500 includes a root category510, associated with the mapped function instance provider, and somenumber of subcategories 520.

The subcategories may be organized in a hierarchical manner as is shownin the diagram, but are not limited to this structure and may beorganized in any other structure, including, but not limited to, a flatlist. If the subcategories are organized in a hierarchical manner, asingle subcategory may commonly be referred to using a notation such as,but not limited to, the following: “Subcategory A/SubcategoryB/Subcategory C.” This notation would locate subcategory C as adescendant of subcategory B, which is in turn is a descendant ofsubcategory A.

When an application 210 requests function instances from the discoveryinterface module 226 and specifies the mapped function instance provider230, the mapped function instance provider 230 uses any providedsubcategory information to locate the specified node 512 in the treestructure 500. Once the specified node 512 has been located, thefunction instance provider uses any API layers 400 associated with thatnode to generate function instances 300.

A node 512 may have zero or more API layers 400. If no API layers 400exist for a given node, then, in some implementations, no functioninstances are returned when that node 512 is specified in a request forfunction instances. A node 512 may have multiple API layers 400. Ifmultiple API layers 400 are specified, then in some implementations, theset of function instances returned consists of function instances fromall specified API layers.

An application 210 may request that function instances 300 should bereturned from the node 512 specified by the subcategory information, aswell as all nodes descended from the specified node. In this case, theAPI layers 400 in the specified node 512 and all descendant nodes 512are used to create function instances.

Turning now to FIG. 6, shown therein is a generalized operational flow600 including various operations that may be performed in a process thatretrieves function instances. The following description of FIG. 6 ismade with reference to the system 200 of FIG. 2. In particular, thedescription of FIG. 6 is made with reference to the function discoverymodule 212, the provider management module 228, and a provider 214.However, it should be understood that the operational flow describedwith respect to FIG. 6 is not intended to be limited to being performedby the function discovery module 212, the provider management module228, or the provider 214. Additionally, it should be understood thatwhile the operational flow 600 indicates a particular order of operationexecution, in other implementations the operations may be ordereddifferently.

As shown, in one implementation of operation 610 the discovery interfacemodule 226 of function discovery module 212 receives a request for a setof function instances 300. This request may include, but is not limitedto, a category; a subcategory; a tree enumeration flag that defines ifonly the subcategory identified by the category and subcategoryinformation should be searched, or if all descendant subcategoriesshould also be searched; and filter criteria that specifies how thereturned function instances 300 should be filtered.

In some implementations, the function discovery module 212 dispatchesthe request to the provider management module 228. In one implementationof operation 612, the provider management module 228 uses the specifiedcategory to identify a provider 214 to service the request for functioninstances 300.

The provider management data 234 may contain information that mapscategories to providers 214. A provider 214 generally corresponds to aparticular type of resource. For example, and without limitation, asingle provider may correspond to any of the following types ofresources: Plug and Play resources, Universal Plug and Play resources,Web Service Discovery resources, Simple Service Discovery Protocolresources, and software components. Providers may also correspond to anyother type of resource.

In one implementation of operation 614, the provider 214 selected inoperation 612 creates and returns function instances 300 identified inthe request. The steps taken by the provider 214 to obtain theinformation necessary for it to create function instances vary byprovider. For example, a provider 214 for Plug and Play resources mayuse an application programming interface specific to interaction withPlug and Play resources 218 to enumerate the resources and retrieveresource metadata information about the resources.

In the case of Plug and Play resources, this application programminginterface may be the SetupDi application programming interface. SetupDiis an API included with certain versions of the Windows® operatingsystem, from Microsoft Corporation of Redmond, Wash. The SetupDi APIenables accessing Plug and Play hardware. In some implementations, themapped function instance provider 230 may use the tree structure 500 andAPI layer 400 data stored in the mapped function instance provider data232 to create function instances.

Finally, in operation 616, in some implementations, the functioninstances 300 created by the provider are returned to the providermanagement module 228, then to the function discovery module 212, thento the discovery interface module 226, and finally to the application210.

It should be noted that the provider 214 might create the functioninstances and return them to the provider management module 228, or itmight return the data necessary to create the function instances andleave the actual creation of the function instances to the providermanagement module 228 or to the function discovery module 212.

It should be further noted that the provider 214 might return functioninstances or data asynchronously from the request for functioninstances. Also, the function instances 300 created by the provider 214might not be complete—that is, they might not contain all of theinformation required to be contained by a function instance. In suchcases, the function discovery module 212, the provider management module228, the discovery interface module 226, or another module, mightsupplement the data in the created function instances 300 before thefunction instances are returned to the requesting application 210.

Turning now to FIG. 7, shown therein is a generalized operational flow700 including various operations that may be performed by a provider 214to service a request for function instances. In particular, theoperational flow 700 illustrates operations that may be performed by aprovider 214 to carry out the determination operation 614 of operationalflow 600.

The following description of FIG. 7 is made with reference to the system200 of FIG. 2. In particular, the description of FIG. 7 is made withreference to the provider management module 228, the providers 214 andresources 218. However, it should be understood that the operationalflow described with respect to FIG. 7 is not intended to be limited tobeing performed by the provider management module 228, the providers214, or the resources 218. Additionally, it should be understood thatwhile the operational flow 700 indicates a particular order of operationexecution, in other implementations the operations may be ordereddifferently.

In one implementation of operation 710, a provider 214 receives arequest for function instances. The request may include, but is notlimited to, a subcategory that identifies a particular set of resourceson which the returned function instances should be based; a treeenumeration flag that defines if only the specified subcategory shouldbe searched, or if all descendant subcategories should also be searched;and filter criteria that specifies how returned function instancesshould be filtered.

In one implementation of operation 712, the provider 214 enumerates theresources 218 with which it's associated and retrieves any informationrequired to create function instances for such resources. Theenumeration can in some cases be limited by the specified subcategoryinformation and in the same or other cases can be limited by thespecified filter criteria information.

The manner in which the provider 214 enumerates resources 218 variesdepending on the nature of the resources with which the providerinteracts. In some cases, the provider 214 may enumerate the resourcesand obtain information necessary to create function instances by usingan application programming interface that is operable to manage theresources. For example and without limitation, a provider 214 for Plugand Play resources 218 may use the application programming interfaceknown as SetupDi. Similarly, a provider for Simple Service DiscoveryProtocol resources may use a Universal Plug and Play applicationprogramming interface to find information about the available UniversalPlug and Play or Simple Service Discovery Protocol resources, etc.

The mapped function instance provider 230 may use the tree structure 500and API layer 400 data stored in the mapped function instance providerdata 232 to create function instances. For example, if the mappedfunction instance provider is given a subcategory of “SubcategoryA/Subcategory B,” it may traverse the tree structure 500 to the nodeassociated with subcategory B and then return function instances definedby the API layer(s) 400 associated with the node associated withsubcategory AB.

Using the information retrieved in operation 712, one implementation ofoperation 714 maps the information to the organization and namingrequired by the function instance. This operation ensures thatapplications 210 using function instances 300 can retrieve the sameinformation with a single name even if the underlying resources namethat information differently. For example, and without limitation,information about the manufacturer of the resource could be representedby the resource-specific application programming interface using a datafield called “ManufacturerName.” This same information—themanufacturer—may be referred to in function instance resource metadata312 as “Manufacturer.” Operation 714 transforms resource data retrievedfrom the resource so that it has the organization and name expected infunction instance resource metadata 312.

In one implementation of operation 716, the provider 214 createsfunction instances 300 for each resource identified by the request. Theprovider may create function instances using, among other things, theresource metadata containing mapped information generated in operation714, any activation information known or retrieved about the resource,and any other information required to create function instances.

Finally, in one implementation of operation 718, the functioninstance(s) 300 the provider 214 has created are returned to theprovider management module 228. It should be noted that the provider 214might create the function instances and return them to the providermanagement module 228, or it might return the data necessary to createthe function instances and leave the actual creation of the functioninstances to the provider management module 228, to the functiondiscovery module 212, or to some other module. Also, the provider 214might return function instances or data asynchronously from the requestfor function instances. In addition, not all of the informationnecessary to create a full and valid function instance might be providedby the provider 214. In such cases, the function instances 300 createdby the provider might not be immediately usable by a requestingapplication 210. For example, the provider might not specify the uniqueidentification value 210; this information might instead be provided bythe provider management module 228, by the function discovery module212, or by some other module.

Turning now to FIG. 8, shown therein is a generalized operational flow800 including various operations that may be performed by a mappedfunction instance provider 230 to service a request for functioninstances 300. In particular, the operational flow 800 illustratesoperations that might be performed by a provider 614 to carry out thedetermination operation 614 of operational flow 800. The followingdescription of FIG. 8 is made with reference to the system 200 of FIG.2, the function instance object 300 of FIG. 2, and the API layer 400 ofFIG. 4. However, it should be understood that the operational flowdescribed with respect to FIG. 8 is not intended to be limited to beingperformed by the system 200, the function instance object 300, and theAPI layer 400. Additionally, it should be understood that while theoperational flow 800 indicates a particular order of operationexecution, in other implementations the operations may be ordereddifferently.

In one implementation of operation 810, a mapped function instanceprovider 230 receives a request for function instances. The request mayinclude, but is not limited to, a subcategory that identifies aparticular set of resources on which the returned function instancesshould be based; a tree enumeration flag that defines if only thespecified subcategory should be searched, or if all descendantsubcategories should also be searched; and filter criteria thatspecifies how returned function instances should be filtered.

In one implementation of operation 812, the mapped function instanceprovider 230 first locates the appropriate node 512 in the treestructure 500 maintained in the mapped function instance provider data232. For example, a request with subcategory information “SubcategoryA/Subcategory B” may define a node 512 that is located at the end of thetree path starting with the root node 510, continuing through the node512 for subcategory A, and terminating with the node 512 for subcategoryB. Once this node is located, the mapped function instance providerretrieves all of the API layer 400 data associated with the node.

Then, for each API layer 400 retrieved in operation 812, the mappedfunction instance provider executes operation 814, which retrieves thefunction instances specified in the API layer 400. The mapped functioninstance provider locates the function instances using the category ofunderlying function instances field 412 and subcategory of underlyingfunction instances field 414.

Additionally, the function instance provider may filter the returnedfunction instances by specified resource metadata 312 property values,or by the returned function instances by supported activation interfaces352, or by some other data. For example, a subcategory named “AudioHardware/Local” might have an API layer 400 with the category field“Plug and Play,” the subcategory field “DevNode,” and a filter on aparticular Plug and Play property, so that only function instances 300that reference audio resources are returned.

In some implementations, operation 814 may be executed multiple timeswhen there are multiple API layers 400 associated with the node 512. Inthis case, the set of retrieved function instances 300 may consist ofall of the function instances returned as a result of the data in eachAPI layer. This enables a single category to contain function instancesthat represent similar resources, even if the underlying functioninstances come from different providers, different categories, ordifferent subcategories.

Next, one implementation of operation 816 creates a new functioninstance for each function instance retrieved in operation 814. This newfunction instance may contain a new unique identifier 310 that isdifferent from the identifier of the underlying function instance onwhich it is based. While the new function instance is based on theunderlying function instance, it is not the same function instance, andso in some implementations warrants its own unique identifier.

The new function instance also contains resource metadata 312 thatcomprises both the resource metadata of the underlying function instanceand the resource metadata from the API layer 400 and mapped functioninstance provider. For example, and without limitation, the resourcemetadata of the new function instance may contain a “Manufacturer” entrywith information from the underlying function instance as well as a“Subcategory” entry that contains the subcategory where the API layer islocated. The underlying function instance contains no information aboutthe subcategory information associated with an API layer, but the mappedfunction instance provider can add this information when it creates thenew function instance.

Finally, the new function instances created in operation 816 alsocontain activation data included in or referenced by the activation datafield 314 and retrieved from the API layer 400. For example, and withoutlimitation, suppose an API layer 400 with a supported interface field418 that contains “Foo Interface” and a corresponding factory field 420that defines an entity that can in turn create another entity thatsupports the Foo interface, based on the information in the functioninstance. Function instances created based on this API layer containactivation data field 314 entries that denote that the function instancesupports the Foo interface and define how to create an entity thatimplements the Foo interface.

The activation data created in operation 816 may also contain activationinformation—in the form of specific interface 352 and factory 354entries—from underlying function instances. This enables “API layering,”where an API is defined in terms of another API. For example, andwithout limitation, suppose that an API layer contains category 412,subcategory 414, and filter criteria 416 information that specifies thatthe underlying function instances (also provided by the mapped functioninstance provider) support the “Complex Interface.”

The API layer that uses these underlying function instances could thencontain a supported interface field 418 that denotes that the resultingfunction instances support the “Simple Interface.” In this case,function instances returned as a result of data in this API layercontain activation data that indicates that they support both the SimpleInterface and the Complex Interface.

Turning now to FIG. 9, shown therein is a generalized operational flow900 including various operations that may be performed by a functioninstance in response to an activation request. The following descriptionof FIG. 9 is made with reference to the system 200 of FIG. 2, thefunction instance object 300 of FIG. 3, and the API layer 400 of FIG. 4.However, it should be understood that the operational flow describedwith respect to FIG. 9 is not intended to be limited to being performedby the system 200, the function instance object 300, and the API layer400. Additionally, it should be understood that while the operationalflow 900 indicates a particular order of operation execution, in otherimplementations the operations may be ordered differently.

In one implementation of operation 910, a function instance 300 receivesan activation request for an object that supports a specifiedapplication programming interface. This request may include, but is notlimited to, an interface that specifies the application programminginterface the returned object supports, and a set of additional datathat, if provided, can be used by function instance to control or modifythe activation.

In operation 912, the function instance 300 determines if it supportsactivation for the requested interface. In one implementation, this testcan be performed by examining the activation data 350 for the presenceof the requested interface, which, if supported, will exist in theinterface column 352. In this implementation, if the interface does notexist in interface column 352, the function instance does not supportactivation for the specified application programming interface.

If it is determined in operation 912 that the function instance 300supports activation for the requested application programming interface,the operational flow 900 continues to operation 916, described below. Ifit is determined in operation 912 that the function instance does notsupport activation for the requested application programming interface,operational flow 900 proceeds to operation 913.

In operation 913, the provider 214 of the underlying resource 218represented by the function instance 300 is queried to determine if theprovider supports activating the requested application programminginterface. If it is determined in operation 913 that the providersupports activating the requested application programming interface, theprovider creates an entity that implements the requested applicationprogramming interface. The operational flow 900 then continues tooperation 920, described below. If it is determined that the providerdoes not support activation for the requested application programminginterface, operational flow 900 proceeds to operation 914.

In operation 914, the activation request indicates that the specifiedapplication programming interface is not supported by the functioninstance 300 or provider 214.

If the function instance 300 supports activation for the requestedapplication programming interface, operational flow 900 continues tooperation 916, where, in one implementation, the function instancecreates a factory associated with the specified application programminginterface. In an implementation using the activation data 350, thefactory column 354 contains an identifier for a factory that createsentities that implement the requested interface. For example and withoutlimitation, the factory column 354 in a COM-based system could contain aCLSID that uniquely identifies a COM object that can create instances ofanother COM object that actually implements the requested interface.Alternatively, and again without limitation, in a .NET or Java-basedsystem the factory column 354 could contain a fully qualified object orpath hierarchy that identifies a .NET or Java object that can createanother object that implements the specified interface. In anon-object-oriented system the factory column 354 could contain anidentifier that specifies how to create some entity that can in turncreate another entity that implements the requested applicationprogramming interface.

In one implementation of operation 918, the factory created in operation916 is used to create an entity that implements the requested interface.The factory has access to the data associated with the functioninstance—like the resource metadata—as well as possibly to other data,like additional parameters included in the activation request. Usingthis data, the factory can create an entity that implements therequested interface.

For example, and without limitation, suppose a function instancerepresents Plug and Play audio hardware, such as a sound card, andsuppose that the activation data 314 denotes that the function instancesupports an “Audio” COM interface. In one implementation, a factoryobject that supports creating COM objects that implement the Audiointerface might use the Plug and Play SetupDi API to create an objectthat implements the Audio interface. Such a factory object could use theresource-specific information in the function instance 300—like anidentifier that specifies which audio hardware the function instancerepresents—to assist in creating the object that implements the Audiointerface.

It should be noted that while this description refers to a factory andto factories creating entities which in turn create other entities thatimplement the requested application programming interface, that thefunction instance 300 could refer directly to the entity that implementsthe application programming interface. In addition, the same entity thatimplements the factory may also implement the application programminginterface.

Finally, in operation 920, the entity implementing the requestedapplication programming interface is returned to the requester.Continuing with the example introduced in the previous paragraph, andwithout limitation, the COM object that implements the Audio interfacewould be returned to the application 210, which could then use it tocontrol and interact with the audio hardware to, for example, play audioor control volume.

Although some particular implementations of systems and methods havebeen illustrated in the accompanying drawings and described in theforegoing Detailed Description, it will be understood that the systemsand methods shown and described are not limited to the particularimplementations described, but are capable of numerous rearrangements,modifications and substitutions without departing from the spirit setforth and defined by the following claims.

1. A method, comprising: receiving at a function instance associatedwith a resource a request for an entity that implements a specifiedinterface, the function instance having activation data that specifiesone or more interfaces; creating the entity that implements thespecified interface; returning the entity that implements the specifiedinterface to the application.
 2. The method of claim 1, wherein theactivation data comprises an association between interfaces andfactories.
 3. The method of claim 1, wherein the activation datacomprises an association between interfaces and factories and whereinthe method further comprises creating a factory associated with thespecified interface.
 4. The method of claim 1, wherein the activationdata comprises an association between interfaces and factories, andwherein the method further comprises creating a factory associated withthe specified interface, and wherein the creating the entity furthercomprises using the factory.
 5. The method of claim 1, wherein themethod further comprises creating a factory associated with thespecified interface.
 6. The method of claim 1, wherein the methodfurther comprises creating a factory associated with the specifiedinterface, and wherein the creating the entity further comprises usingthe factory.
 7. The method of claim 1, wherein the creating the entityfurther comprises using a resource provider.
 8. The method of claim 1,wherein the creating the entity further comprises using a resourceprovider and wherein the resource provider is associated the functioninstance.
 9. One or more computer-readable media containingcomputer-executable instructions that, when executed, implement thefollowing steps: receiving at a function instance associated with aresource a request for an entity that implements a specified interface,the function instance having activation data that specifies one or moreinterfaces; creating the entity that implements the specified interface;returning the entity that implements the specified interface to theapplication.
 10. The one or more computer-readable media of claim 9,wherein the activation data comprises an association between interfacesand factories.
 11. The one or more computer-readable media of claim 9,wherein the activation data comprises an association between interfacesand factories and wherein the instructions further comprise creating afactory associated with the specified interface.
 12. The one or morecomputer-readable media of claim 9, wherein the activation datacomprises an association between interfaces and factories, and whereinthe instructions further comprise creating a factory associated with thespecified interface, and wherein the creating the entity furthercomprises using the factory.
 13. The one or more computer-readable mediaof claim 9, wherein the instructions further comprise creating a factoryassociated with the specified interface.
 14. The one or morecomputer-readable media of claim 9, wherein the instructions furthercomprise creating a factory associated with the specified interface, andwherein the creating the entity further comprises using the factory. 15.The one or more computer-readable media of claim 9, wherein the creatingthe entity further comprises using a resource provider.
 16. The one ormore computer-readable media of claim 9, wherein the creating the entityfurther comprises using a resource provider and wherein the resourceprovider is associated the function instance.
 17. One or morecomputer-readable media having embodied therein: means for selecting afactory entity from a plurality of factory entities based on a requestfrom an application for an object that implements a specified resourceinterface; means for creating the object using the factory entity; andmeans for returning the object to the application.
 18. The one or morecomputer-readable media of claim 17, wherein the factory entity is a COMobject.
 19. The one or more computer-readable media of claim 17, whereinthe interface is a COM interface.
 20. The one or more computer-readablemedia of claim 17, wherein the means for selecting a factory entityfurther comprises using information specified by API layers.